1. Field of the Invention
The present invention relates in general to a debugging system for displaying waveform data produced by an integrated circuit simulator or verification tool and in particular to a debugging system that also graphically represents relationships between circuit behavior and structure to help a user analyze circuit behavior.
2. Description of Related Art
FIG. 1 is a schematic diagram modeling a portion of an integrated circuit (IC) receiving five input signals D–H produced by other modules of the circuit. A register 10 stores input signals D–H on an edge of an input clock signal CLK2 to produce a set of three control signals (RST, LD and SEL) and two 8-bit data signals (A and B) at the output of register 10. When SEL is low (0) an arithmetic logic unit (ALU) 12 adds A and B to produce output data C supplied as input to an accumulator 14 clocked by another input clock signal CLK1. When SEL is high (1) ALU 12 subtracts B from A to produce its output data C. Accumulator 14 increments its output value ACC by C in response to an edge of another clock signal CLK1 when the reset (RST) and load (LD) signals are both low. When RST is high, accumulator 14 sets its output equal to 0 and when LD is high, it sets its output signal equal to C. A register 16 stores the ACC signal on leading edges of the CLK2 signal to produce an output signal OUT.
While the schematic model of the circuit of FIG. 1 helps people understand the structure of the circuit, an integrated circuit (IC) designer typically creates a text-based “netlist” circuit model written in a hardware description language that can be processed by various computer-aided design (CAD) tools, including a circuit simulator that can simulate how an IC described by a netlist would behave over time in response to a set of input signals.
As illustrated in FIG. 2, an IC designer programs a simulator 18 with instructions including a netlist 17 describing an IC to be simulated and a “testbench” file 20 describing how the circuit's input signals vary with time during the simulation. Simulator 18 then simulates the response of the circuit to the input signals described by testbench 20 and produces a “dump file” 22 containing a set of waveform data sequences, each describing how a separate one of the IC's input or generated signals varies with time. A debugger 24 then generates a display 26 of the waveform data results of the simulation included in dump file 22.
FIG. 3 illustrates an example waveform display 26 that debugger 24 might produce based on waveform data a simulator 18 might write to a dump file 22 while simulating a circuit including the circuit module of FIG. 1. The waveform display of FIG. 3 shows how input clock signals CLK1 and CLK2 and generated control and data signals SEL, LD, RST, A, B, C, and ACC signals vary with time. Debugger 24 may allow a user to provide “expect” data 28 as input indicating expected values of various signals at selected times so that the debugger may flag any signal that fails be of an expected value at an expected time. In FIG. 3 a flag 30 indicates that the ACC data signal was expected to transition to a value 54 at a time 980 when it actually transitioned to value 34.
The dump file 22 that simulator 18 produces, and the waveform display 26 debugger 24 derives from the dump file, are behavioral models of the circuit, describing how a circuit behaves by describing how the signals it receives and generates behave. But the dump file and the waveform display say nothing about the structure of the circuit or how the signals are interrelated. Thus while the waveform display of FIG. 3 can tell a designer that the ACC signal has an unexpected value at time 980, the waveform display alone does not provide the designer much help in determining the cause of the problem; it can't tell him why the ACC signal had value 34 after time 980 instead of its expected value 54 because it does not include any information relating the behavior of the ACC signal to the behavior of any other signal.
To understand why the ACC signal changed to value 34 at time 980, the designer will typically review not only the behavioral model of the circuit (the waveform display), but also a structural model of the circuit (the netlist or schematic). For example, netlist 17 or the schematic of FIG. 1 would tell the designer that the value of the ACC signal following an edge of the CLK1 signal is a function of values of signals C, LD, RST and ACC when the CLK1 edge occurred. The designer could determine by looking at the netlist and the waveform display that C had value 34 and the LD signal was high (1) at time 980 when CLK1 clocked accumulator 14, so that the accumulator output ACC would have been set equal to C at that time. Thus the designer might concluded that the error may have arisen because C had the wrong value at time 980 or because the LD signal was incorrectly asserted at time 980.
To investigate whether the error in ACC arose from an error in the C signal, the designer could determine from the netlist that ALU 12 produces its output data signal C as the sum of data signals A and B when SEL is low and as the difference of A and B when SEL is high. From the waveform display of FIG. 3, the designer would see that at time 980, A and B had values 44 and 10, respectively, and that SEL was high. Thus ALU 12 would have subtracted 10 from 44 to generate a C signal having value 34. Noting that the expected value of ACC, and therefore the expected value of C at time 980 should have been 54, the designer might suspect that the SEL control signal should have been low instead of high at time 980 so that B would be added to A instead of subtracted from A, thereby causing C to transition to 54 instead of remaining at 34. The designer might also wonder whether A should have transitioned to 64 at time 980. The designer would then go on to investigate the structure and behavior of the circuit module producing the F and G signals from which the SEL and A signals are derived, perhaps to discover a logic error in that module. However the source of an error in waveform data is not always so easy to find.
Netlist 17 provides an instruction statement for each signal generated by the IC indicating that the value of the signal is a function of one or more other of the circuit input or generated signals, and that the statement is to be periodically evaluated on each edge of a clock signal. For example the statement defining the behavior of accumulator 14 of FIG. 1 would describe the value to which the ACC output of the accumulator should be periodically set as a function of its own current value and the values of RST, LD and C, and the statement would indicate that it is to be evaluated on each edge of the (simulated) CLK1 signal.
A simulator's evaluation of a netlist statement, thereby setting the value of an IC signal at a particular simulation time, is herein defined as a “statement event”. FIG. 4A graphically illustrates how statement events relate to one another. An output signal value generated during a statement event 32 at a time 100 is a logical function of data values generated during statement events 33 and 34 occurring at earlier times 90 and 80. Signal values acting as inputs to statement events 33 and 34 are in turn generated as outputs of several statement events occurring at still earlier times 80 and 70. Note that the “fan-in cone” formed by statement events having an influence on the output value of statement event 32 at time 100 grows rapidly as the designer looks farther back in time. When an identified error in a signal value produced by statement event has its roots in statement events occurring far back in time from the identified error event, designers can find the problem of locating the cause of an error to be tedious and complex.
In addition to determining how a signal came to have a particular value at a particular time, a designer might like to determine how a change in a value of a signal at a particular time might affect values of other signals at later times. For example, looking at the waveform displays of FIG. 3, the designer might want to know what would happen if the RST signal value stayed low at time 770 instead of going high for one CLK2 cycle. What other signals would be affected during next N clock cycles, and how would they be affected? FIG. 4B illustrates a “fan-out” cone indicating how a signal value generated by a statement event 36 occurring at time 40 can affect values generated by an increasingly larger number of statement events as time passes. While a designer might be able to determine how a change in the data value produced by a particular statement event might affect outputs of statement events for the next few clock cycles, the process can become increasing difficult as the designer's investigation continues to move forward in time, particularly when the effects of the statement event fan out as illustrated in FIG. 4B.
A designer might also like to know how a change in a statement defining a portion of the logic of a circuit might affect some small portion of circuit behavior, but that can be difficult for a designer to determine without modifying the netlist and re-running the entire simulation, which can be time-consuming.
What is needed is a debugger that can provide a user with a better picture of the relationship between circuit structure and circuit behavior, that can help the designer to quickly determine and visualize how a change in a signal value output of a statement event affect signal value outputs of later statement events.